Displaying queue information in a graphical user interface of an issue tracking system

ABSTRACT

Methods for displaying improved user interfaces are disclosed. The method includes receiving a user interface request to display a user interface of an issue tracking system from a user device. The user interface displays a plurality of objects and the user interface request includes a user identifier of a user of the user device and a user identifier of the requested user interface. The method further includes determining a time since the user last viewed the user interface, retrieving object data for the requested user interface based on the user interface identifier, retrieving activity data for the requested user interface based on the time since the user last viewed the user interface, and communicating the object data and activity data to the user device for displaying on the user device, the user device displaying the object data and displaying one or more activity indicators based on the received activity data.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This application is a continuation patent application of U.S. patentapplication Ser. No. 17/565,368, filed Dec. 29, 2021 and titled“Displaying Queue Information in a Graphical User Interface of an IssueTracking System,” the disclosure of which is hereby incorporated hereinby reference in its entirety.

TECHNICAL FIELD

Aspects of the present disclosure are directed to graphical userinterfaces, and in particular, to improved graphical user interfaces.

BACKGROUND

Oftentimes, users view summary user interfaces that display a pluralityof items and data associated with these items. For example, user mayview a dashboard that shows all the intellectual property assets ownedby a company at different stages in their lives. In other examples, auser working in a service helpdesk may wish to view a list of pendingissues/tickets that the user and/his or her team has to handle. In stillanother example, a user may wish to view a user interface that displaysa list of software bugs identified in a given software product.Similarly, a user may wish to view a planner dashboard showing aplurality of tasks to be performed in different stages of completion.

Although such user interfaces typically display the data the user wishesto view, they do not do so in an efficient manner. The data may bedisplayed in a cluttered manner and/or in a manner that increases thecognitive burden on users and increases the time required to performactions. Accordingly, it is desirable to have more efficient andimproved graphical user interfaces that reduce the cognitive burden onusers and/or reduce the time taken to perform tasks.

SUMMARY

Example embodiments described herein are directed to acomputer-implemented method. The method includes receiving a userinterface request to display a user interface of an issue trackingsystem (ITS) from a user device. The user interface displays a pluralityof objects of the ITS. The user interface request includes a useridentifier of a user of the user device and a user identifier of therequested user interface. The method further includes determining a timesince the user last viewed the user interface, retrieving object datafor the requested user interface based on the user interface identifier,retrieving activity data for the requested user interface based on thetime since the user last viewed the user interface, and communicatingthe object data and activity data to the user device for displaying onthe user device one or more objects of the plurality of objects of theITS based on the object data and one or more activity indicators for thedisplayed one or more objects of the plurality of objects of the ITSbased on the activity data.

Other example embodiments described herein are directed to anothercomputer-implemented method. The method includes generating a requestfor displaying a user interface of an issue tracking system (ITS) thatdisplays a plurality of objects of the ITS. The request includes anidentifier of the user interface, and an identifier of the user of auser device. The method further includes communicating the request to aserver and receiving object data and activity data from the server inresponse to the user interface request. The activity data indicates newactivity in one or more objects of the plurality of objects since theuser last viewed the user interface. The method further includesdisplaying the object data in a plurality of object cards; and using theactivity data to display activity indicators against one or more objectcards corresponding to the one or more objects that have new activity.

Some example embodiments are directed to a system. The system includes aprocessor and a non-transitory computer readable medium comprisinginstructions, which when executed by the processor, cause the system toperform the operations of the methods described above.

Other example embodiments are directed to non-transitory computerreadable medium which when executed by a processor causes the processorto perform the methods described above.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings:

FIG. 1 illustrates a conventional issue panel.

FIG. 2 illustrates an example summary user interface (UI) according toaspects of the present disclosure.

FIG. 3 is a block diagram depicting a networked environment in whichvarious features of the present disclosure may be implemented.

FIG. 4 is a block diagram of a computer processing system configurableto perform various features of the present disclosure.

FIG. 5 illustrates is an example database schema.

FIG. 6 is a flowchart illustrating an example method for displaying asummary UI according to aspects of the present disclosure.

FIG. 7 is a flowchart illustrating an example method for refreshing thesummary UI according to aspects of the present disclosure.

FIG. 8 is a flowchart illustrating an example method for performing anaction via the summary UI according to aspects of the presentdisclosure.

FIG. 9 is an example summary UI showing an action being performed.

FIG. 10 is an example summary UI showing another action being performed.

While the description is amenable to various modifications andalternative forms, specific embodiments are shown by way of example inthe drawings and are described in detail. It should be understood,however, that the drawings and detailed description are not intended tolimit the embodiments to the particular form disclosed herein. Theintention is to cover all modifications, equivalents, and alternativesfalling within the scope of the present disclosure as defined by theappended claims.

DETAILED DESCRIPTION

In the following description, numerous specific details are set forth inorder to provide a thorough understanding of the various embodimentsdisclosed herein. It will be apparent, however, that the embodimentsdisclosed herein may be practiced without these specific details. Insome instances, well-known structures and devices are shown in blockdiagram form in order to avoid unnecessary obscuring.

For instance, the user interfaces of the present disclosure aredescribed with reference to an issue tracking system (ITS) and inparticular with reference to a user interface of an ITS system thatdisplays a summary view of multiple issues belonging to a project orqueue. It will be appreciated however that this is merely exemplary andthat the teachings of the present disclosure can be adopted in userinterfaces that display a plurality of items/resources/objects and theircorresponding data for any software application and in any format. Forinstance, it may be used in user interfaces that display a list ofdocuments hosted by a content management system. In fact, it may be usedin any user interface that displays a plurality of objects that may beupdated from time to time. For instance, aspects of the presentdisclosure may be utilized to display task cards in an object trackingsystem such as Trello, Microsoft Planner, and so on.

Overview

An ITS provides users with the ability to create and track issues—or,more generally, work items. A work item is an item with associatedinformation and an associated lifecycle—i.e., a series of states throughwhich the work item transitions over its lifecycle. The lifecycle for agiven work item may be simple (e.g., an open state and a closed state)or more complex (e.g., open, closed, resolved, in progress, andreopened).

The particular information and lifecycle associated with a work item mayvary greatly depending on the scenario in which the ITS is implemented.By way of example, an ITS may be implemented in a helpdesk scenario, inwhich case the work items may be issues or tickets logged with thehelpdesk. An ITS may be implemented in a project management scenario, inwhich case the work items may be project tasks. An ITS may beimplemented in a software development scenario, in which case work itemsmay be bugs, current features under development, and/or featuresintended for further development. An ITS may be implemented in anorganizational administration scenario, in which case work items may beadministrative forms (e.g., leave request forms or the like). An ITS maybe used in an organization's customer support center to create, update,and resolve reported issues by customers and/or employees. Many otherITS implementations in which different work items are tracked throughdifferent lifecycles are possible. For ease of reference, the followingdisclosure will refer to issues, however the features and operationsdescribed could apply to any other type of work item maintained by anITS.

One example of an ITS with which the present disclosure may beimplemented is Jira Service Management (JSM), which is commerciallyavailable from Atlassian. For the purposes of explanation the presentdisclosure will predominantly refer to JSM, however the featuresdescribed herein could be applied to alternative issue tracking systems.

When an ITS is used to handle a small number of issues or work items atany given time, it is relatively easy to assign these work items toagents and easy for the agents to check and manage the issues assignedto them. However, when an ITS is used by a large organization to handlesthousands if not hundreds of thousands of issues—management of issuesbecomes difficult. To help with this, some ITSs allow the creation andmanagement of queues. A queue includes a list of issues that have one ormore common underlying parameters, e.g., common location, common issuetype, common priority type, etc. For example, a helpdesk ITS for amulti-national company with offices in New York, London, and Dubai, maysetup three different queues—New York issues, London issues, and Dubaiissues. New issues received or created by the ITS are then assigned toone of these queues depending on which office the issues related to.Similarly, organizations can create queues based on any other parameterssuch as issue types, issue priority, workflow status (e.g., open,unassigned, assigned, closed, resolved, in progress, reopened, and soon).

Even though queues help segregate issues, they may not completely helpwith reducing cognitive burden on the user. For example, in case a queueincludes multiple issues, a user may have to review each issue in thequeue frequently to determine the state of the issue (e.g., whether theissue has been resolved or is still pending, whether any new activity,such as a comment from a user has been submitted in the issue, and soon. The more issues included in a queue the more daunting the landingexperience becomes for a new team member joining an existing queue, oreven for existing team members.

FIG. 1 illustrates a conventional summary user interface 100. This userinterface 100 may be the first interface an agent sees when they selecta particular queue/project from a queue panel, a list of projects, adropdown list, and so on. As seen in FIG. 1 , the summary user interface100 includes multiple issues belonging to a corresponding queue/project.For example, the summary user interface 100 may show a list of activeissues belonging to the ‘New York Pending’ queue for a helpdesk ITS fora multi-national company. There may be thousands of issues in this queuewhich an agent may need to work through.

The issues 102 are shown in a table format in this example and for eachissue, the table shows an issue identifier 104A, status 104B, summary104C, reporter 104D, created date 104E, updated date 104F, and due date104G. In other examples, there may be other issue-related informationdisplayed in the user interface corresponding to each issue. Forexample, the user interface may also or alternatively display the agentan issue is assigned to, the project an issue belongs to, etc.

Typically, the summary user interface 100 displays all the active issuesin a queue. And, agents typically do not have any control over themanner in which the issues are displayed in the user interface 100.Instead, the agent typically has to select an issue from the list ofissues and view a detailed issue user interface to determine what hasbeen updated and if there are any tasks for the agent to perform or not.Further, if a particular queue includes multiple OPEN or IN PROGRESSissues, the agent may have to view each such issue in a detailed userinterface to determine whether any actions need to be taken.

Accordingly, the list of issues displayed in the user interface 100 maybe cumbersome and cluttered, create an unsatisfactory UI experience andmay increase the time taken by a user to manage issues and may increasethe cognitive burden on the user. For example, an agent may not be ableto easily navigate issues that have already been actioned or evendecipher the priority of different issues.

To overcome one or more of these issues, aspects of the presentdisclosure provide more efficient issue management systems and methods.In some embodiments, the present disclosure provides mechanisms todeclutter user interfaces that display a plurality of objects whosestates may changes frequently such that users may experience a moreefficient and visually decluttered interface that reduces the cognitiveburden on users and produces a more engaging human machine interface. Inparticular, some aspects of the present disclosure replace the tabularstructure of known conventional list-based UIs with flexible userinterface formats that can be configured into different display formatsto adapt to different ways of working. For example, the tabularstructure can be replaced by a card-based design, such that each objectis displayed in its own interactive and/or moveable card along withobject data. By displaying object data in cards instead of a tablereduces the amount of data displayed in the UI creating a more visuallydecluttered queue. Further, card-based design allows more space forspecific issue fields, such as a description field, to be displayed inthe summary user interface. This may be advantageous where teams dealwith detailed descriptions and work could be expedited by reading thesedescriptions directly from the summary user interface without having toopen the detailed view of the corresponding issues. Further, issueinformation displayed in the cards can be configurable, such that agentscan customize their UIs to suit their needs. In another example, thetabular structure may be replaced by a calendar or timeline view thatshows each object as an interactive card in a calendar or timeline. Bydisplaying object data in a calendar or timeline view, users can quicklydetermine overdue issues/tasks and may be able to take action for themmore effectively. Within the different configurable display formats,users may be able to further customize display by adjusting filters,sorting and other aspects like columns or date ranges, etc.

In some embodiments, the UI of the present disclosure displays updatesin activity data of the individual objects in the UI. As used in thisdisclosure, activity data refers to any data that may indicate any typeof activity associated with an object. In an ITS, activity data mayinclude, e.g., new comments on issues, change in issue status, creationor closure of issues, mentions in an issue, new issue assignments of anissue to a user, and so on.

Different indicia or markers may be used to indicate different types ofactivity update data. For example, if an issue has been resolved, thecolor of the issue name or the issue card can be changed to a differentcolor such as green. Similarly, if new unassigned issues exist in aqueue, the issue names can be updated to bold and/or the issue cardcolor can be updated to a different color, such as red. Additionally oralternatively, the shape, size or format of the issue card can bechanged to highlight activity update data. If new comments have been anissue in the list includes new comments, a chat icon or emoji may bedisplayed next to the issue name, and so on.

Further, the UI as disclosed herein can be configured to show multipletypes of activity data (such as change in issue status and/or newcomments). The configuration may be performed by users oradministrators. Further, it may be possible to show different types ofactivity data for objects belonging to different queues/projects. Forinstance, for objects belonging to one queue/project, the UI may displayactivity update data whenever the status of an object changes or a newunassigned object is added whereas for objects belonging to anotherqueue/project, the UI may be configured to display activity update datawhenever new comments are made with respect to an object or the userviewing the UI is mentioned.

In some embodiments, the activity data displayed in the issue UI may beconfigurable by the user such that the UI displays activity data that isimportant to that user.

The activity data may be updated based either on a polling method—wherethe client requests refreshes at fixed intervals or based on apublish-subscribe model—where the server sends updates to the client atfixed intervals or whenever there is a change. In either case, if afixed interval is used, the refresh rates may be predetermined, set byan agent, or dynamically changed based on server loads—if the serverload is below a threshold, refresh rates for different groups may beincreased and if server loads are above a threshold, the refresh ratesmay be decreased.

In some embodiments, in addition to displaying updated activity data,the UI of the present disclosure may be configured to allow users toperform actions directly from the UI. For example, in the ITS example,users may be able to update an assignee of an issue or respond to acomment directly from the UI. This way, the user does not have to selectan issue, view a detailed view of the issue and then update the assigneeof the issue via the detailed view UI. This saves a number of keypresses/clicks and reduces the need to request the server to provide andrender the detailed view UI for an issue, thereby saving user andmachine time, and processor and server utilization.

FIG. 2 shows an example summary UI 200 according to aspects of thepresent disclosure. The summary UI 200 displays a plurality of objects(e.g., issues in this example) as object cards 202. Further, the UIincludes one or more sort controls 204 to allow the object cards to besorted as desired. In the present example, the objects are sorted indate order (e.g., based on the date the issues were created). In otherexamples, the sort control 204 may allow the object cards 202 to besorted in other date orders, such as date updated/modified. Sortcontrols 204 may be provided to allow the cards 202 to be sorted basedon any other parameters such as status, time to resolution, reporter,etc.

Further, the UI 200 includes one or more filter controls 206 to allowthe object cards 202 displayed in the UI 200 to be filtered based on acondition/parameter associated with the object or issue, such as issuestatus, issue creation/update date, time to resolution, assignee,reporter, etc.

The object cards 202 themselves show data about the correspondingobject—including e.g., object identifier, object name, current status,time to resolution (if any), reporter and assignee. In addition, theobject cards may include interactive controls (e.g., selectableaffordances) that allow particular actions to be performed to thecorresponding objects. For example, object cards 202 may include aninteractive control 208 which when selected causes the card 202 to bepinned (such that it is displayed in the summary UI 200 irrespective ofthe filters applied or displayed at the top of the UI irrespective ofthe sort control 204 applied to the objects). In another example, theobject cards 202 may include an interactive control 210 that allows thecorresponding objects to be ‘snoozed’ or hidden from the summary UI 200.The snooze/hide control 210 may allow the user to snooze objects for aparticular period (e.g., 1 day, 1 week, and so on) or until a particularactivity occurs (e.g., issue status changes, issue is assigned to theuser, comment is received, and so on). For example, an issue cardassociated with new hardware for a customer may be snoozed until the newhardware arrives. In some embodiments, when the snooze control 210 isselected a pop-up window 211 may be displayed that allows the user toinput the end date or trigger condition for the snoozed object to beunsnoozed and optionally to provide a comment. The comment may be usefulin case the snooze is applied for a long period and the user forgets whythey had snoozed the object or in other cases where the snooze isapplied to the object for the entire user's team.

In yet another example, the object cards 202 may include an interactivecontrol 213 that allows a reminder to be set. For instance, a user maywish to set a reminder on an issue to follow-up with a customer after 5days if no comments are received from the customer. In some cases, likethe snooze control 210, when the reminder control 213 is selected, thecorresponding object card 202 may be hidden from the user interface 200until it is time for the reminder. In other cases, the object card mayremain in the user interface 200.

In some embodiments, when the reminder control 213 is selected a pop-upwindow (not shown) may be displayed that allows the user to input thereminder date and reminder text. Then, on the reminder date, thereminder text may be displayed to the user in a suitable way—e.g., byshowing the object card 202 with the reminder control highlighted. Whena user hovers over the reminder control 213, a pop-up window may displaythe reminder text. Additionally or alternatively, a pop-up window withthe reminder text may be displayed automatically when the user scrollsto the corresponding object card 202. In other examples, the remindermay be displayed as part of the activity update.

In this case, the user could activate the snooze feature for 5 days andadd a note reminding the user to contact the customer once the issuecard is ‘unsnoozed’.

The summary UI 200 also displays an activity indicator 212 showingactivity updates. In the UI displayed in FIG. 2 , activity indicators212 are displayed against object cards 202A, 202B and 202C indicatingthat some new activity has occurred in the corresponding objects (issuesin this example UI). The activity indicator 212 is displayed as a solidline against a side of the object cards in this example. However, itwill be appreciated that this is just one example of an activityindicator 212 and that in other examples, different visual indicatorsmay be used without departing from the scope of the present disclosure.For example, in other embodiments, the activity indicator 212 may changethe color of a corresponding object card 202, highlight the object card202, and/or add a shape such as a star, or a circle in the object cardor near the object card 202, change the shape, size, color of the objectcard, etc.

The aim of the activity indicator 212 is to quickly allow a user to scanthe summary UI 200 and distinguish the objects that have had activityupdates from the objects where no activity update has taken place. Itmay take any physical form to enable this.

In addition to indicating that activity updates are present for one ormore objects, the UI 200 also displays information about the type ofactivity that has taken place. In the example shown in FIG. 2 , when auser hovers over or selects the activity indicator 212, additionalinformation about the activity update is presented in a pop-up window214. In this example, the activity update information indicates that theissue includes two new messages and an attachment.

In some examples, the pop-up window 214 may include interactiveinformation. For example, a user may be able to select or hover over the“2 Messages” text in the pop-up window 214, which in turn may cause afurther pop-up window 216 to appear that shows the two new messages andmay even allow the user to respond to the messages directly from thepop-up window. Similarly, if the user selects or hovers over the “1attachment” text in the pop-up window 214, a preview of the attachmentmay be displayed to the user in a further pop-up window (not shown).This way, a user can review the updated object information directly fromthe summary UI 200 without having to inspect each object via thedetailed object view UI. This not only saves user time but also savesprocessing and network bandwidth as the user device does not have toretrieve and display all the data for the object in the detailed viewUI.

These and other features of the summary UI 200 will be described indetail in the following sections.

Environment Overview

FIG. 3 depicts an example networked environment 300 in which variousoperations and techniques described herein can be performed. Exampleenvironment 300 includes a communications network 302, whichinterconnects user device 310 and a product platform 320.

The user device 310 may be any device suitable for performingclient-side operations described herein, for example a mobile device(e.g. a tablet or mobile phone), a portable device (such as laptopcomputer), or any other computing device (e.g. a desktop computer).While only one user device 310 have been illustrated, an environmentwould typically include multiple user devices 310 interacting with theproduct platform 320.

Users of the user device 310 are associated with one or more useraccounts and generate and/or communicate electronic content to theproduct platform 320. This includes any type of user account interactionwith the product platform 320, including, for example, interacting with(i.e., sending data to and receiving data from) product platform 320,and viewing or interacting with summary UIs (such as summary UI 200)displayed on a display of the user device 310.

In order to allow users to perform these functions, as illustrated inFIG. 3 , the user device 310 includes one or more client (software)applications (e.g., client 312) that is configured to accessapplications made available by the product platform 320. The client 312may communicate with the application hosted by the product platform 320,render user interfaces (e.g., the summary UI 200) based on instructionsreceived from the product platform server 322, and receive inputs fromuser accounts allowing them to interact with the applications hosted bythe product platform 320.

The client 312 includes instructions and data stored in the memory (e.g.non-transitory compute readable media) of the user device 310 on whichthe application is installed/run. These instructions are executed by aprocessor of the user device 310 to perform various functions asdescribed herein. By way of example, some functions performed by theclient 312 include communicating with the software application hosted bythe product platform 320, rendering user interfaces (e.g., showing issuedata) based on instructions received from the product platform 320,receiving inputs from users to interact with user interfaces madeavailable by the product platform 320, and communicating user inputs tothe product platform 320 to update data managed by the product platform320.

The client 312 further includes an UI module 314 configured to managesummary UIs. In particular, the UI module 314 may be configured tocommunicate with the product platform 320 to receive e.g., issue dataand activity update data for display in a summary UI, to receive userinputs in the summary UI, and to perform actions based on user inputs.

The client 312 may be implemented in various ways. For example, theclient 312 may be a web browser application, which accesses theapplications hosted by the product platform 320 via appropriate uniformresource locators (URL) and communicates (using a communicationinterface such as 418 described below) with the product platform 320(and, in particular, the server application 322) via generalworld-wide-web protocols. In this case, the web browser application isconfigured to request, render and display user interfaces that conformto a mark-up language, and may be capable of internally executingbrowser-executable code, or other forms of code. Alternatively, theclient 312 may be a specific application programmed to communicate withthe product platform 320 using defined application programming interface(API) calls.

The product platform 320 may be a system or set of systems configured toprovide any type of service/perform any type of operations for clients112. In order to provide such services/operations, product platform 320stores object data in an object data store 323. As one example, productplatform 320 may be an ITS used (inter alia) to create, manage, andtrack issues. Product platform 320 may, however, provide otherservices/perform other operations. In the present example, productplatform 320 includes a server application 322.

Server application 322 is executed by a computer processing system toconfigure that system to provide server-side functionality to one ormore corresponding client applications 312—e.g., by receiving andresponding to requests from client applications 312, storing/retrievingdata from the data store 323, and performing other operations asdescribed herein. Server application 322 comprises one or moreapplication programs, libraries, APIs or other software elements thatimplement the features and functions that are described herein. Forexample, where the client application 312 is a web browser, the serverapplication 322 is a web server such as Apache, IIS, nginx, GWS, and/oran alternative web server. Where the client application 312 is aspecific/native application, server application 322 is an applicationserver configured specifically to interact with that client application312.

In one example, the server application 322 includes a UI manager 327configured to manage the display of summary UIs. In particular, the UImanager 327 may be configured to communicate with the UI module 314 ofuser devices 310, retrieve, e.g., summary data and activity data fromdata store 324, communicate summary data and activity data to the UImodule 314 for rendering on the user devices, perform actions based onuser input received in summary UIs from user devices 310, etc. Theserver application 322 may further include an automation module 328 thatis configured to monitor trigger conditions for snoozed object cardsand/or reminders, to determine when unsnoozing or reminder conditionsare met, schedule unsnoozing/reminder events, and communicateunsnoozing/reminder events to the UI manager 327 once theunsnoozing/reminder events have occurred. The UI manager 327 in turn canremove corresponding issue/reminder data from the data store 323.

The data store 323 is used to store data related to the product platformapplication. For example, in case the product platform is an ITS, thedata store may include, e.g., data defining the operation of the ITSapplication (for example, user accounts, user permissions, and the like)as administrative data 326; and issue data 325 (e.g., issue name, issueID, issue status, issue workflows, and so on).

The issue data 325 may include one or more data structures, for example,including issue data (e.g., issue identifier, issue name, date created,reporter, assignee, and so on). These data structures will be describedin more detail below.

The data store 323 may be provided by a database server (not shown)which may be hosted by server 322, but is more typically hosted on aseparate physical computer in communication (directly or indirectly viaone or more networks 302) with the server 322. While a single data store323 is described, multiple separate data stores could be provided.

While single server architecture has been described herein, it will beappreciated that the server 322 and data store 323 can be implementedusing alternative architectures. For example, in certain embodiments,the product platform 320 is a scalable system including multipledistributed server nodes connected to one or more shared data stores(e.g. shared file servers). Depending on demand from clients (and/orother performance requirements), product platform 320 server nodes canbe provisioned/de-provisioned on demand to increase/decrease the numberof servers offered by the product platform 320. Each server 322 may runon a separate computer system and include one or more applicationprograms, libraries, APIs or other software that implement server-sidefunctionality. Similarly, the data store 323 may run on the samecomputer system as an server application 322, or may run on their owndedicated system(s) (accessible to server application(s) 322 eitherdirectly or via a communications network).

Communications between the various systems in environment 300 are viathe communications network 302. Communications network may be a localarea network, public network (e.g., the Internet), or a combination ofboth.

While environment 300 has been provided as an example, alternativesystem environments/architectures are possible.

Hardware System

The embodiments and features described herein are implemented by one ormore special-purpose computing systems or devices. For example, inenvironment 300 each of the user devices 310 and the product platform320 is or includes a type of computing system.

A special-purpose computing system may be hard-wired to perform therelevant operations described herein. Additionally or alternatively, aspecial-purpose computing system may include digital electronic devicessuch as one or more application-specific integrated circuits (ASICs) orfield programmable gate arrays (FPGAs) that are persistently programmedto perform the relevant operations. Alternatively, a special-purposecomputing system may include one or more general-purpose hardwareprocessors programmed to perform the relevant operations pursuant toprogram instructions stored in firmware, memory, other storage, or acombination.

A special-purpose computing system may also combine custom hard-wiredlogic, ASICs, or FPGAs with custom programming to accomplish therelevant operations described herein. A special-purpose computing systemmay be a desktop computer system, a portable computer system, a handhelddevice, a networking device or any other device that incorporateshard-wired and/or program logic to implement relevant operations.

By way of example, FIG. 4 provides a block diagram that illustrates oneexample of a computer system 400, which may be configured to implementthe embodiments and features described herein. Computer system 400includes a bus 402 or other communication mechanism for communicatinginformation, and a hardware processor 404 coupled with bus 402 forprocessing information. Hardware processor 404 may be, for example, ageneral-purpose microprocessor, a graphical processing unit, or otherprocessing unit.

Computer system 400 also includes a main memory 406, such as a randomaccess memory (RAM) or other dynamic storage device, coupled to bus 402for storing information and instructions to be executed by processor404. Main memory 406 also may be used for storing temporary variables orother intermediate information during execution of instructions to beexecuted by processor 404. Such instructions, when stored innon-transitory computer readable media accessible to processor 404,render computer system 400 into a special-purpose machine that iscustomized to perform the operations specified in the instructions.

Computer system 400 further includes a read only memory (ROM) 408 orother static storage device coupled to bus 402 for storing staticinformation and instructions for processor 404. A storage device 410,such as a magnetic disk or optical disk, is provided and coupled to bus402 for storing information and instructions.

In case the computer system 400 is the user device 310, the computersystem 400 may be coupled via bus 402 to a display 412 (such as an LCD,LED, touch screen display or other display), for displaying informationto a computer user. An input device 414, including alphanumeric andother keys, may be coupled to the bus 402 for communicating informationand command selections to processor 404. Another type of user inputdevice is cursor control 416, such as a mouse, a trackball, or cursordirection keys for communicating direction information and commandselections to processor 404 and for controlling cursor movement ondisplay 412.

According to one embodiment, the operations described herein areperformed by computer system 400 in response to processor 404 executingone or more sequences of one or more instructions contained in mainmemory 406. Such instructions may be read into main memory 406 fromanother storage medium, such as a remote database. Execution of thesequences of instructions contained in main memory 406 causes processor404 to perform the process operations described herein. In someembodiments, hard-wired circuitry may be used in place of or incombination with software instructions.

The term “storage media” as used herein refers to any non-transitorycomputer readable media that stores data and/or instructions that causea machine to operate in a specific fashion. Such storage media maycomprise non-volatile media and/or volatile media. Non-volatile mediaincludes, for example, optical or magnetic disks, such as storage device410. Volatile media includes dynamic memory, such as main memory 406.Common forms of storage media include, for example, a floppy disk, aflexible disk, hard disk, solid state drive, magnetic tape, or any othermagnetic data storage medium, a CD-ROM, any other optical data storagemedium, any physical medium with patterns of holes, a RAM, a PROM, andEPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge.

Storage media is distinct from, but may be used in conjunction with,transmission media. Transmission media participates in transferringinformation between storage media. For example, transmission mediaincludes coaxial cables, copper wire, and fiber optics, including thewires that comprise bus 402. Transmission media can also take the formof acoustic or light waves, such as those generated during radio waveand infrared data communications.

Computer system 400 also includes a communication interface 418 coupledto bus 402. Communication interface 418 provides a two-way datacommunication coupling to a communication network, for examplecommunication network 302 of environment 300. For example, communicationinterface 418 may be an integrated services digital network (ISDN) card,cable modem, satellite modem, etc. As another example, communicationinterface 418 may be a local area network (LAN) card to provide a datacommunication connection to a compatible LAN. Wireless links may also beimplemented. In any such implementation, communication interface 418sends and receives electrical, electromagnetic, or optical signals thatcarry digital data streams representing various types of information.

Computer system 400 can send messages and receive data, includingprogram code, through the network(s) 302 and communication interface418.

As noted, computer system 400 may be configured in a plurality of usefularrangements, and while the general architecture of system 400 may bethe same, regardless of arrangements there will be differences. Forexample, where computer system 400 is configured as a server computer(e.g. such as product platform 320), it will typically be provided withhigher end hardware allowing it to process data, access memory, andperform network communications more rapidly than, for example, a userdevice (such as user device 310).

Example Data Structures

This section describes some of the data structures maintained in thedata store 323. In this example, the product platform is assumed to bean ITS and the data store 323 is assumed to store issue-related datastructures. The data structures and fields described below are providedby way of example. Depending on the implementation, additional, fewer,or alternative fields may be used. Further, the fields described inrespect of a given data structure may be stored in one or morealternative data structures (e.g., across multiple linked datastructures). Although tables are used to illustrate the data structures,the relevant fields/information may be stored in any appropriateformat/structure.

An ITS may maintain a list of issues in a variety of data structures. Inone embodiment, issues are stored in a relational database (e.g., indata store 323). By way of illustration, FIG. 5 provides a partialexample of a simple relational database schema 500 for an ITS. In thisexample, schema 500 includes: an issue table 502 comprising an issue IDfield, an application/service ID field, a timestamp of when the issuewas created, a status ID field, an issue summary field; anapplication/service table 504 comprising an application/service IDfield, and an application/service description; a status table 506comprising a status ID field and a status description field; and apeople table 508 comprising an assignee ID field, an owner ID field, anda reporter ID field.

Schema 500 has been provided for descriptive purposes, however arelational database schema for an ITS is typically considerably morecomplex and can have additional/different tables withadditional/alternative fields and linked in alternative ways.Furthermore, different data structures entirely could, in some cases, beused. For example, issues could be stored in a single table datastructure (which may be appropriate for relatively simple ITSs) wherethe single table stores all relevant issue data. The table belowprovides an example of a simple single table data structure for storingissues:

TABLE A Example issue data structure App/Service Key ID DescriptionStatus Priority Date/time . . . . . .

In addition to the general issue data described above—that applies toall users that wish to view issue data, the schema 500 may also storeissue data that pertains to specific users or teams. For example, theschema 500 may include a relational table associated with each issuethat includes pinned data. For instance, the relational table mayinclude identifiers of users/teams that may have pinned thecorresponding issue in their summary user interfaces. Table B shows anexample of one such database below—

TABLE B Example pin database associated with a given issue UserIdentifier Context Identifier 879483 Queue 44 242340 Queue 12 242340Queue 22 Team_abc Queue 11

Each such table may be associated with a given issue.

Similarly, the schema 500 may include another relational tableassociated with each issue that includes snooze data. For instance, therelational table may include identifiers of users/teams that may havesnoozed the corresponding issue in their summary user interfaces. TableC shows an example of one such database below—

TABLE C Example snooze database associated with a given issue UserContext Snooze Snooze Identifier Identifier Start time duration Snoozetrigger Comment 879483 Queue 44 23, Dec. 2021 5 days — Snoozed ashardware not 10:00:01 expected until next Monday Team_abc Queue 12 21,Dec. 2021 Hardware asset Snoozed until hardware field updated received242340 Queue 22 1, Dec. 2021 5 days Snoozed until hardware arrivesGlobal Queue 11 28, Nov. 2021 Hardware asset — field updated

Each such table may be associated with a given issue. As seen in thisexample, the same issue may be snoozed by particular users in theirqueues or it may be snoozed globally by an administrator. If a usersnoozes an issue before it has been globally snoozed, the user specificsnooze may be maintained in the table or it may be removed.

A similar relational table may be maintained for reminder data. Forinstance, the relational table may include identifiers of users/teamsthat may have set reminders for the corresponding issue in their summaryuser interfaces. Table D shows an example of one such database below—

TABLE D Example reminder database associated with a given issue UserContext Reminder Reminder Identifier Identifier Start time durationReminder message 879483 Queue44 23, Dec. 2021  5 days Check if customer10:00:01 has responded 342649 Global 21, Dec. 2021 10 days Check ifDavid has returned the laptop

Each time a user or administrator pins, unpins, snoozes, or sets areminder on a given issue, the issue identifier and the correspondingaction data is communicated to the server 322, which communicates thedata to the data store 323 to update the corresponding table B, C or D.For example, if an issue is pinned, snoozed or a new reminder is set, anew record may be added in table B, C, and/or D of the given issue.Additionally or alternatively, if an issue is unpinned, an unsnooze orreminder condition has been met (as determined by the automation module328), the corresponding record from table B, C, or D is removed.

It will be appreciated that although the pinned, snooze and reminderdata is shown as being stored along with issue data in the issue schema500, this need not always be the case. In other implementations, theserver 322 may maintain independent data tables for pinned, snooze andreminder data. In such cases, the data tables may also include the issueidentifier and/or project identifier in each record.

Example Methods

FIG. 6 is a flowchart illustrating an example method for displaying asummary UI according to some aspects of the present disclosure. Themethods are also described with reference to an ITS as the productplatform 320, issues as the items/objects/resources maintained by theproduct platform and issue data as the item/object/resource datadisplayed in the summary UI 200. However, it will be appreciated thatthis is an example. The method 600 commences at operation 602, where theuser device 310 receives a request to display a summary UI. This requestmay be received in a number of different ways.

In one example, a user may be viewing a queue panel/user interface thatdisplays a plurality of issue queues. The user may then wish to view oneof the issue queues and may select the particular issue queue. Selectionof the issue queue results in generation of a summary UI request. Inanother example, a user may be viewing a user interface displaying aplurality of projects and may select a project. This selection causesgeneration of a summary UI request. In another example, a user may havebookmarked or otherwise saved the URL for the summary page of aparticular issue queue/project. In this example selecting the bookmarkor entering the URL in the address bar or a web browser may result inthe summary UI request being generated.

At operation 604, the UI request is communicated to the product platform320 (e.g., ITS). In one example, the UI request includes a uniqueidentifier of the user interface for which the summary is requested, anda unique identifier of the user making the request. In case the userinterface is displayed by an ITS, the user interface identifier may be aqueue/project identifier. In addition, in some embodiments, the requestmay include a timestamp indicating the time since the user last viewedthe UI. It will be appreciated that in some cases, the user may haveselected one or more filters in their UI 200. In such cases, the UIrequest also includes data about the filter applied by the user. Thisdata may be saved in the UI module 314. If the UI allows pinning ofissue cards, the UI request may include a request for the ‘pin’ fielddata to be returned along with issue data such that the client 312 canidentify and distinguish pinned data.

At operation 606, the UI manager 327 receives the request and atoperation 607 the UI manager 327 determines a time since the user lastviewed the requested summary UI. In some embodiments, this determinationmay be made based on the timestamp received from the user device 310. Inother embodiments, the UI manager 327 may save a data structure thatstores data indicating the last time a user viewed a given summary UI.Table E shows an example data structure that store the user identifier,UI identifier, and last viewed timestamp.

TABLE E Example last viewed data structure User ID UI ID Time lastViewed 327463872 Queue: 44 23, Dec. 2021 10:10:00 . . . . . . . . .

In one example, whenever the UI manager 327 receives a request to view agiven summary UI (e.g., associated with a given queue or project), itmay inspect the data structure to check if a record already exists forthe given user identifier and summary UI identifier. If a record exists,the UI manager 327 may update the timestamp in the record based on thecurrent time. If a record does not exist for that user identifier andsummary UI identifiers, a new record is added in the data structure andthe current time is added as the last viewed timestamp. By storing thelast viewed data structure in the server 322, the system can determinewhen a user last viewed a particular UI on any device.

At operation 608, the UI manager 327 retrieves object data (e.g., issuedata) for the requested summary UI. The object data corresponds to thedata displayed in the object cards 202. In one example, the UI manager327 creates a search query based on the received UI identifier (e.g.,project/queue identifier) and uses this to query the issue datastructure 500. In case the UI request also includes filter data, thisdata may be added to the search query such that issues that match thefilter criteria are returned. For example, if the filter criteria is allpending issues, the UI manager 327 can update the search query toinclude, e.g., AND (Issue status=“pending”).

If the UI also includes other UI configurable options such as pinning orsnoozing, the UI manager 327 may update the search query such thatissues pinned by the user or the user's team are returned or issuessnoozed by the user and/or the user's team are not returned with thesearch results. For example, the search query can be updated to adde.g., ‘AND (snoozes !=currentUser( ) OR snoozes !=“ALL”)’). Similarlypinned issues would be part of a union in the query (e.g., ‘OR(pins=pinUserAndContext(currentUser( ) “queue:42”)’).

Once the issue identifiers are retrieved, the UI manager 327 can querythe ITS issue data structure 500 to retrieve data that is to bedisplayed in the object cards 202 for each issue. In some examples, theclient 312 may specify the issue data fields to be retrieved. In otherexamples, the UI manager 327 may have a list of data fields that are tobe displayed in the cards—these may be default fields—and may query thedata structure 500 with the issue identifiers and the data fields(self-supplied or received from the client 312) to retrieve datacorresponding to the fields displayed in the issue card. This data maybe packaged and communicated to the user device 310.

In addition to the issue information, at operation 608, the UI manager327 also determines activity update data for the retrieved activeissues. In one example, the activity update data is determined based onthe last viewed date/time determined at operation 607 and the updateddate/time associated with the active issues. If the updated date/time ofthe issue is after the last viewed date/time, the UI manager 327determines that the corresponding issue has been updated since the userlast viewed the issue and may add the issue identifier of that issue toan activity update list. This check is performed for all the activeissues identified at operation 606. The update list may include issuesthat were created after the time the user last viewed the summary UI. Itwill be appreciated that if an issue has been pinned, unpinned, orunsnoozed since the last time the user viewed the summary UI 200, thepinning, unpinning or unsnoozing may be reflected as an update in theissue data and if the corresponding issue identifier matches the searchquery criteria, this pinning, unpinning, or unsnoozing may be added asactivity update data. Similarly, if a reminder condition is met sincethe last time the user viewed the summary UI 200, the reminder may bereflected as an update in the issue data and if the corresponding issueidentifier matches the search query criteria, the reminder may be addedas activity update data.

In one example, the activity data may simply include the update list ofissue identifiers for which activity updates are present. This may beuseful in cases where the UI includes an activity indicator that isseparate from activity information. In such cases, the UI manager 327may initially communicate the update list of issue identifier as part ofthe activity update data and this may be used by the client 312 todisplay activity indicators 212 for issue cards that have correspondingupdates. If the user wishes to view the activity data in detail, theuser may hover over or select the corresponding activity indicator 212,which can initiate a second request to the server 322 and in particularto the UI manager 327 to retrieve and communicate information about theactivity that has been updated.

In other examples, the activity data may include a list of issueidentifiers for which activity updates are present and information aboutthe various changes that have occurred in the issue since the user lastviewed the summary UI. For example, this information may include a countof the number of messages/comments made in the issue, any change inissue status or issue assignment, the content of the newmessages/comments, new documents/attachments added to the issue, anypinning, unpinning, unsnoozing of issue cards, any reminders, etc.

In either case, at operation 610, the UI manager 327 communicates theissue data and activity update data to the client 312 for display on theuser device 310.

At operation 612, the user device receives the issue data and activitydata and generates the summary UI (e.g., such as summary UI 200). Inparticular, the client 312 generates issue cards based on the receivedissue data and generates activity indicators 212 based on the list ofissues received in the update list. Additionally or alternatively, theclient 112 may display activity data in any other suitable manner. Forexample, new messages/comments may be displayed via a highlighted chaticon in a corresponding card, changes in issue status may be displayedin a different color, content of new messages or new documents may bedisplayed in pop-up windows, pinning/unpinning may be shown byhighlighting the pin affordance 208, unsnoozing may be shown byhighlighting the issue card and the snooze control 210 and a remindermay be shown in a pop-up when the user hovers over the correspondingissue. If the UI manager 327 communicates additional activity data(e.g., in the form of JAVASCRIPT components), the client 312 maydownload and execute these components and store the executed componentsin a local cache for display when the user hovers over or selects acorresponding activity indicator 212.

In this manner, aspects of the present disclosure can display a summaryUI on a user device.

FIG. 7 is a flowchart illustrating an example method 700 for displayingissue updates while the user is viewing a summary UI. In particular, itprovides a method for updating activity data for displayed issues inreal time while the summary UI is being displayed on a user device 310.

In some examples, the UI manager 327 pushes issue updates to the userdevices either in real time (i.e., whenever an issue is updated) or atpredetermined intervals (e.g., every 10 seconds, every 60 seconds, andso on). In other cases, the client 312 may pull issue updates from theITS in real time, e.g., by utilizing web hooks (programmed into thesoftware application hosted by the ITS) that notify the client 312 whenissue updates are available at the ITS or by requesting the ITS atpredetermined intervals (e.g., every 30 seconds, every minute, every 5minutes, etc.) to provide issue updates that were generated in thatinterval.

Method 700 describes one example method for displaying issue updatesbased on the client 312 generating and communicating update requests tothe ITS at predetermined intervals. However, it will be appreciated thatthe method 700 can be amended slightly to be able to display issueupdates according to any of the other push or pull techniques describedabove.

The method commences at operation 702, where the UI module 314 initiatesa counter for the predetermined interval of time.

Next, at operation 704, the UI module 314 determines whether the counterhas expired.

If the UI module 314 determines that the counter has not expired, themethod returns to operation 704.

Additionally or alternatively, if the UI module 314 determines that thecounter has expired, the method proceeds to operation 706.

At operation 706, the UI module 314 generates a refresh request for thesummary UI. The refresh request includes queue/project identifierassociated with the summary UI, identifiers of any filters implementedby the user, an identifier of the user making the request, a time stampcorresponding to the time the UI was previously updated.

It will be appreciated that agents may not wish to be informed of allissue updates. For example, agents may not be interested in receivingupdates if the number of minutes since the issue has been active isupdated. Similarly, an agent may not be interested in receiving updatesfor actions performed by that agent. However, they may be interested inreceiving updates when other agents have performed actions or customershave commented on issues, if the state of an issue changes, etc.Accordingly, either the agents or administrators may configure thesummary UI such that it only displays activity indicators 212 whenrelevant updates occur. Accordingly, the refresh request may furtherinclude a list of data fields for which activity update data isrequested.

At operation 708, the refresh request is communicated to the server 322and in particular the UI manager 327.

Next, at operation 710, the UI manager 327 receives the refresh requestand at operation 712 the UI manager determines the activity data updatefor the requested queue/project. To this end, the UI manager 327 mayquery the data store and in particular, the issue data 325 in the datastore 323 to retrieve the activity update data for the requested queue.In one example, it may identify the issues that have been updated bycomparing the timestamp received from the client 312 with the latestupdated timestamp of the corresponding issues. If the updated timestampindicates a time after the time indicated by the timestamp received fromthe client, the UI manager 327 determines that the corresponding issuehas been updated. It may also determine whether the updated data fieldsof these updated issues match one or more of the data fields receivedfrom the client 312 in the refresh request. If the updated data fieldsmatch the one or more received data fields, the corresponding issueidentifiers are added to the activity update data. The UI manager 327performs this identification for all the issues corresponding to thequeue/project identifier. Further, for the issues that were updatedsince the last refresh request and that match the received data fields,the UI manager may determine whether the user requesting the update madeany of those updates. This may be done by comparing the user identifierreceived as part of the refresh request with the user identifiers ofusers that last updated the given issues. If any issues are identifiedin this check as being updated by the requested user, those issueidentifier can be removed.

In some cases, the update information may also be added to the activityupdate data.

If a new issue has been added to the queue/project since the last timethe client 312 requested an update, the create date/time of the issuewill be after the time indicated in the timestamp received from theclient 312. In this case, the UI manager 327 may also retrieve issuedata corresponding to the newly added issue and add it to the activityupdate data.

Once the requested activity update data for the queue/project isdetermined and retrieved, the UI manager 327 communicates the activityupdate data back to the client 312 (at operation 714). In one example,the response includes the queue/project identifier and the correspondingactivity data update.

At operation 716, once the client 312 and in particular the UI module314 receives the updated activity data from the server 322 it updatesthe local cache (if required, e.g., if in addition to the issueidentifiers the activity update data includes the actual updateinformation) and updates the summary UI. For example, for issues thathad previously not been updated, but have been updated now, the UImodule 314 may display an activity indicator 212. For new issues, it maygenerate and display a new issue card and (in some examples) an activityindicator 212.

The method then returns to operation 704.

FIG. 8 is a flowchart illustrating an example method for performing atransformative action via an issue card or activity update window. Incase transformative actions are allowed, the corresponding issue cardsor activity update window contents may be interactive. FIG. 9illustrates an example summary UI that allows users to performtransformative actions directly from an issue card. In this example, theassignee affordance 902 is interactive. For example, a user may selectthe assignee affordance 902 in an issue card to be able to change theassignee directly from the issue card. In this example, a pop-upassignee selector control 904 is displayed to the user. The user mayenter an assignee name in the text bar 906 or select an assignee from adrop down list.

Similarly, FIG. 10 illustrates another example summary UI that allows auser to perform a transformative action directly from an activity updatewindow 214. In this example, the pop-up window 216 showing the two newcustomer comments includes an interactive reply button 1002. A user canselect the reply button 1002, which cause a further comment pop-upwindow 1004 with an editor to be displayed. The user can add a commentusing the editor and either save the comment or cancel the operation.

In addition, the user may be able to perform actions that do notnecessarily update the underlying issue, but may alter the user'ssummary UI view. For example, the user may be able to pin one or moreissues using control 208 so that the issues appear in the summary viewdespite any filters applied by the user. In another example, the usermay be able to snooze an issue, e.g., using control 210, so that theissue is hidden from the summary view for a period of time or until aparticular action occurs. Similarly, the user may be able to add areminder for an issue.

To aid in description of this process, an example summary UI isconsidered that includes one or more interactive graphical elementsrepresenting transformative actions that may be performed on thecorresponding issue directly from the summary view. It will beappreciated that the summary UI need not always include actionableitems, let alone a transformative actionable items.

At operation 802, the client 312 detects selection of a particularactionable graphical element.

In response, the client 312 identifies the action corresponding to theselected graphical element and generates an action message at operation804. The message includes the action that the user wishes to perform, auser identifier, an issue identifier of the issue for which the actionis to be performed and in some examples, the identifier of thequeue/project the user is currently viewing. For example, if the userwishes to update the assignee for a given issue, the action messageincludes data about the old assignee, the assignee selected by the user,the issue identifier of the issue for which the assignee is selected,and an identifier of the user that performed the action. Similarly, ifthe user adds a new comment in response to a particular comment, theaction message includes the comment, the identifier of the comment thatthe user responded to, an identifier of the issue and an identifier ofthe user that wrote the comment. In another example, if the user wishesto pin a particular issue, the action message includes the identifier ofthe issue to be pinned, the identifier of the user, and the identifierof the queue/project the user is currently viewing.

This action message is forwarded to the ITS at operation 806. The ITSmay provide a particular endpoint for servicing action requests fromsummary Uls. This endpoint, also referred to as an action URL, isavailable at the client 312. The client 312 retrieves the action URLfrom its local cache and forwards the action message to the endpointcorresponding to the action URL.

It will be appreciated that sometimes a user may have permission to viewa particular issue (because the user has view permissions for theunderlying content), but the user may not have sufficient permission tomodify/write to the issue. Accordingly, at operation 808, the UI manager327 determines whether the user is allowed to perform the action. Knownaccess permission methods may be employed (including key or token basedpermissions) to make this determination and this operation is notdescribed in detail here.

If the UI manager determines that the user has permission to perform theaction, the method 800 proceeds to operation 810 where the UI manager327 performs the action on the issue. For example, it may update theassignee of the issue, add the user comment to the issue data, add a newrecord in the pin data table B for the given issue. Once the action hasbeen successfully performed, the UI manager 327 may forward a successmessage to the client 312 at operation 812.

The client 312 in turn updates the summary UI at operation 814 toreflect that the action has been successfully performed. For example, incase the user had changed the assignee, the corresponding issue card isupdated to show the avatar/name of the newly assigned person.Alternatively, if the comment has been updated, editor and reply/cancelbuttons may disappear and the user comment may be added to the commentpop-up window 1004. Similarly, if the issue has been pinned, theinteractive control 208, may change into a non-interactive highlightedpin icon.

Additionally or alternatively, if at operation 808 it is determined thatthe user is not allowed to perform the action, an unsuccessful messageis generated at operation 816 and passed back to the user device 310 atoperation 818.

The client 312 may then update the user interface to indicate that theuser is not permitted to perform the action (e.g., by removing theaction buttons, interactive controls) or may indicate that the actionwas unsuccessful by showing an error message, or in some other manner.

In some cases, although the user may have permission to perform theaction, the action may nonetheless not be successfully performed (e.g.,because the action is no longer available at the source, the action hasalready been performed by another user, or the ITS timed out). In suchcases, the server 332 may generate and forward a suitable error messageto the user device 310 to inform the user that the action was notsuccessfully performed. In some cases, the user may be given the optionto try again and in other cases the action graphical elements may beremoved. It will be appreciated that these are only two possible waysand that other techniques may also be contemplated to inform the userthat the action was unsuccessful and these other techniques are withinthe scope of the present disclosure.

The flowcharts illustrated in the figures and described above defineoperations in particular orders to explain various features. In somecases the operations described and illustrated may be able to beperformed in a different order to that shown/described, one or moreoperations may be combined into a single operation, a single operationmay be divided into multiple separate operations, and/or the function(s)achieved by one or more of the described/illustrated operations may beachieved by one or more alternative operations. Still further, thefunctionality/processing of a given flowchart operation couldpotentially be performed by different systems or applications.

Unless otherwise stated, the terms “include” and “comprise” (andvariations thereof such as “including,” “includes,” “comprising,”“comprises,” “comprised” and the like) are used inclusively and do notexclude further features, components, integers, operations, or elements.

Although the present disclosure uses terms “first,” “second,” and so onto describe various elements, these terms are used only to distinguishelements from one another and not in an ordinal sense.

It will be understood that the embodiments disclosed and defined in thisspecification extend to alternative combinations of two or more of theindividual features mentioned in or evident from the text or drawings.All of these different combinations constitute alternative embodimentsof the present disclosure.

The present specification describes various embodiments with referenceto numerous specific details that may vary from implementation toimplementation. No limitation, element, property, feature, advantage orattribute that is not expressly recited in a claim should be consideredas a required or essential feature. Accordingly, the specification anddrawings are to be regarded in an illustrative rather than a restrictivesense.

What is claimed is:
 1. A computer-implemented method of providing a userinterface of an issue tracking system, the method comprising: receivinga user interface request to display the user interface of the issuetracking system (ITS) from a user device; causing display of a set ofissue cards to be displayed in the user interface on the user device,each issue card of the set of issue cards corresponding to a respectiveissue managed by the ITS, each issue card including a set of interactivecontrols; for each issue card of the set of issue cards, obtaining issueobject data for the respective issue managed by the ITS; for one or moreissue cards of the set of issue cards, obtaining respective activitydata corresponding to one or more actions performed during a time sincethe user interface was previously viewed; causing at least a portion ofthe issue object data to be displayed in each respective issue card ofthe set of issue cards; causing display of one or more activityindicators for the one or more issue cards for which activity data wasobtained; and in response to a user selection of a particularinteractive control of the set of interactive controls for a particularissue card of the set of issue cards, causing an action selected fromthe plurality of actions to be performed with respect to a particularissue associated with the particular issue card, the action performedwith respect to the particular issue on the ITS, wherein the pluralityof actions is chosen from a list including: a pin action, a snoozeaction, a reminder setting action and an issue assign action.
 2. Thecomputer-implemented method of claim 1, wherein: the reminder settingaction defines a time at which a reminder for the particular issue willbe displayed in the user interface.
 3. The computer-implemented methodof claim 1, wherein: the snooze action suppresses display of theparticular issue card within the user interface for a predefined amountof time.
 4. The computer-implemented method of claim 1, wherein: theissue assign action causes display of an assignee selector control, theassignee selector control includes a list of user identifiers; and inresponse to a user selection of a particular user identifier of the listof user identifiers, cause a user account associated with the particularuser identifier to be assigned to the particular issue in the ITS. 5.The computer-implemented method of claim 1, wherein the one or moreactivity indicators includes a respective graphical element positionedalong a side of a respective issue card.
 6. The computer-implementedmethod of claim 1, wherein the action to pin the issue card causes theparticular issue card to remain displayed within the user interface. 7.The computer-implemented method of claim 6, wherein pinned object cardscorresponding to the action to pin the object card are displayed in atop portion of the user interface.
 8. A computer-implemented method ofproviding a user interface of an issue tracking system, the methodcomprising: receiving a user interface request to display the userinterface of the issue tracking system (ITS) from a user device; causingdisplay of a set of issue cards to be displayed in the user interface onthe user device, each issue card of the set of issue cards correspondingto a respective issue managed by the ITS, each issue card including aset of interactive controls; for each issue card of the set of issuecards, obtaining issue object data for the respective issue managed bythe ITS; arranging the set of issue cards based at least in part on atimestamp of each issue card of the set of issue cards; causing at leasta portion of the issue object data to be displayed in each respectiveissue card of the set of issue cards, the issue object data includingthe timestamp; and in response to a user selection of a particularinteractive control of the set of interactive controls for a particularissue card of the set of issue cards: causing an action selected from aplurality of actions to be performed with respect to a particular issueassociated with the particular issue card, the action performed withrespect to the particular issue on the ITS, wherein the plurality ofactions is chosen from a list including: a pin action, a snooze action,a reminder setting action and an issue assign action; and updatingdisplay of the user interface in accordance with the action performed.9. The computer-implemented method of claim 8, wherein in response to auser interaction over a region of the particular issue, causing displayof additional issue data.
 10. The computer-implemented method of claim9, wherein additional issue data includes an activity updatecorresponding to the particular issue.
 11. The computer-implementedmethod of claim 8, wherein the timestamp corresponds to a date of issuecreation.
 12. The computer-implemented method of claim 8, wherein: theissue assign action causes display of an assignee selector control, theassignee selector control includes a list of user identifiers; inresponse to a user selection of a particular user identifier of the listof user identifiers, cause a user account associated with the particularuser identifier to be assigned to the particular issue in the ITS; andthe updated display of the user interface includes an assigned user thatcorresponds to the user selection of the particular user identifier. 13.The computer-implemented method of claim 8, wherein: the snooze actionsuppresses display of the particular issue card within the userinterface for a predefined amount of time.
 14. The computer-implementedmethod of claim 8, wherein the updated display includes a change incolor of the particular issue card.
 15. A computer-implemented method ofproviding a user interface of an issue tracking system, the methodcomprising: receiving a user interface request to display the userinterface of the issue tracking system (ITS) from a user device; causingdisplay of a set of issue cards to be displayed in the user interface onthe user device, each issue card of the set of issue cards correspondingto a respective issue managed by the ITS, each issue card including aset of interactive controls; for each issue card of the set of issuecards, obtaining issue object data for the respective issue managed bythe ITS; causing at least a portion of the issue object data to bedisplayed in each respective issue card of the set of issue cards; inresponse to a user selection of a particular interactive control of theset of interactive controls for a particular issue card of the set ofissue cards: obtaining user permissions data for the user; and inaccordance with the user satisfying a permissions criteria, causing anaction selected from a plurality of actions to be performed with respectto a particular issue associated with the particular issue card, theaction performed with respect to the particular issue on the ITS,wherein the plurality of actions is chosen from a list including: a pinaction, a snooze action, a reminder setting action and an issue assignaction.
 16. The method of claim 15, wherein the user permissions dataincludes modify or write permission of an underlying contentcorresponding to the particular issue card.
 17. The method of claim 15,comprising: subsequent to causing the action to be performed withrespect to the particular issue, causing an updated display of theparticular issue card in accordance with the action performed.
 18. Themethod of claim 17, comprising: in response to the action to beperformed with respect to the particular issue failing to be performed,causing an updated display of the particular issue card indicating thatthe action failed.
 19. The method of claim 15, wherein: the action to beperformed includes adding a comment to the particular issue card; and inaccordance with the user satisfying a permissions criteria, causedisplay of a pop-up window having a comment area.
 20. The method ofclaim 19, comprising: subsequent to a user satisfying the permissionscriteria and inputting the comment in the pop-up window, updatingdisplay of the particular issue card, the updated display comprising thecomment.